Actually this is a good point, I keep running into this issue where I forget to unset RTE_SDK, and it really doesn't work, so maybe we should do this too.

Applied. Thanks!

Yeah, the original idea was to allow users to use their own version of DPDK, although I never tested this scenario myself. :)

Our changes from the original configuration are:

• CONFIG_RTE_BUILD_COMBINE_LIBS=y (was n)
• CONFIG_RTE_LIBNAME="dpdk" (was intel_dpdk)
• CONFIG_RTE_LIBRTE_KNI=n (was y)
• CONFIG_RTE_LIBRTE_VHOST=y (was n)

The first one allows us to not enumerate all the individual dpdk components in Makefile. The libname was changed since "dpdk" is default in 2.1. KNI causes build errors with very recent kernel versions, but anyways we have our own vport so KNI is not required.

Given that none of them are strictly required to build BESS (VHOST is the only exception, but we can selectively load the driver by checking CONFIG_RTE_LIBRTE_VHOST in vhost_driver.c), I thought supporting custom DPDK would be not a bad idea.

I think we have three options in the long term:

1. Forcing deps/dpdk
2. Enumerating all DPDK components in our Makefile (we used to do this)
3. Using DPDK-provided Makefile (as long as it's not too intrusive): http://dpdk.org/doc/guides/prog_guide/dev_kit_build_system.html#makefile-description

Comments? :)